With the ever-increasing frequency of software product updates and the continually improving ease of patch distributions and applications, software vendors increasingly find it difficult to correctly update a software application using patches given the variety of prior patches that may or may not have been previously applied to a particular customer's machine. For example, if a software vendor has already released four patches for a particular product, a customer's machine may have none, some, or all of the previously released patches when an installation application is applying a fifth patch to the customer's machine. This creates a problem if the fifth patch requires the presence of one or more of the previous four patches. Moreover, the installation application may not apply the patches in a correct order. Thus, each patch must correctly handle different possible orderings of the earlier patches. Detecting and correctly handling possible orderings of earlier patches may incur prohibitive costs. For instance, the total number of orderings in the case of four earlier patches is roughly 42. But with five earlier patches, the total number of orderings jumps to 207.
Complicating the problem, an installation engine typically applies patches to a software product in the order in which the installation engine encounters the patches on a customer's machine. This chronological ordering of patches is limited to the most basic patching scenarios. A patch may easily install an incorrect version of a file if a user instructs the installation application to apply an older patch for the software product after the installation application had already applied a newer patch to the machine.
In addition, patch authors often attempt to use other attributes of the product (e.g., product version) to enforce some forms of sequencing behavior. But the fact that these attributes were not created to solve sequencing problems limits their effectiveness and flexibility. Thus, while this approach may be effective in blocking incorrect patch applications in some scenarios, its usefulness is generally limited to when a patch is a minor upgrade patch that changes the product version. This approach also provides little functionality for creating a flexible set of patches that may apply a fix or update to several different versions of a software product or patches that may maintain a valid state when the application applies or removes other, perhaps unrelated, patches from the software product.
Furthermore, existing patching techniques do not maintain state information when updates to the product are physically delivered to the product before being installed on the target machine.
Accordingly, a solution that effectively provides sequencing of various patches for updating a software product is desired.